home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
CD ROM Paradise Collection 4
/
CD ROM Paradise Collection 4 1995 Nov.iso
/
graphics
/
dxlib50.zip
/
DONTREAD.ME
< prev
next >
Wrap
Text File
|
1995-02-11
|
52KB
|
886 lines
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;+ +
;+ DONTREAD.ME Version 2.0 +
;+ A Tutorial for XLIB and Protected Mode +
;+ +
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;
; If you don't read much, then this file was made just for you. It's
;a lot shorter than XLIB.DOC. It also explains several protected-mode
;concepts, including some that are needed to understand XLIB.DOC. We work
;through an assembly language program which demonstrates the usage of XLIB.
;As we go, we are going to do a lot of talking about protected mode in
;general as well as protected mode under XLIB in particular.
; First, let's talk about what XLIB is generally designed to do: XLIB
;will allow you to write protected-mode procedures using your familiar
;language development tools (compilers, linkers, etc), and will allow you to
;execute code containing such procedures using DOS. XLIB is also designed
;to make all this as simple for you as it possibly can. That turns out to
;very simple indeed.
; XLIB has one major shortcoming: It relies on DOS to load executables
;and files. This means that our code must reside in the first meg because
;that's the only thing DOS knows how to work with. It also means that when
;we transfer disk files to or from extended memory, we must perform a
;transfer through a buffer in the first meg. In almost every other regard,
;we will have unlimited power. Most importantly, we will be able to access
;data in extended memory with extreme ease and speed.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Now, let's start with a little program. We must begin with a model
;declaration. XLIB is a large-model library which uses PASCAL conventions.
;We will use the same model here; however, this is not a requirement of XLIB.
;We will use the FARSTACK option because this ensures that our real-mode
;stack will be at the end of the program. This is where it should be under
;most circumstances anyway, but TASM doesn't always put it there (see the
;section on bugs in README.DOC). FARSTACK allows us to conclude that the
;initial SS:SP points to the end of the program. This will become useful
;information a few lines down. We also want to tell the assembler to let us
;use 32-bit instructions. We do this with the .386 directive.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.MODEL LARGE,PASCAL,FARSTACK
.386
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; The next two line are the key ingredients. We want to provide XLIB
;symbols to this program with XLIB.INC. We also want to link with XLIBE.LIB.
;XLIBE.LIB has exception trapping capabilities whereas XLIB.LIB does not.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
INCLUDE XLIB.INC
INCLUDELIB XLIBE.LIB
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;TASM Only:
;
; If you are a TASM programmer, then don't use the last two lines. Use the
;following lines instead. These lines include some useful macros that should
;have been in TASM to begin with.
;
; MASM51 ;Emulate MASM51
; QUIRKS ;MASM51 quirks are sometimes nice
;
;PUSHW MACRO IMMEDIATE16:REST ;PUSH 16-bit constant
; IF (@WordSize EQ 4)
; DB 66H
; ENDIF
; DB 68H
; DW IMMEDIATE16
; ENDM
;
;PUSHD MACRO IMMEDIATE32:REST ;PUSH 32-bit constant
; IF (@WordSize EQ 2)
; DB 66H
; ENDIF
; DB 68H
; DD IMMEDIATE32
; ENDM
;
; INCLUDE XLIBB.INC
; INCLUDELIB XLIBEB.LIB
;
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Now we will finish our simplified segment directives.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.STACK 1024
.DATA
.CODE
.STARTUP
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Now we have to deal with an annoying complication. XLIBE.LIB might need
;to allocate some conventional memory for its own use. The problem is that
;our program has likely claimed all available memory, even though it isn't
;going to use it. If you are a MASM programmer, then the solution is simple:
;Link with the CPARM:1 parameter. If you are a TASM programmer, then you
;must resize the memory block in which this program is contained. The
;following code will do the trick. This code is also contained in the file
;RESIZE.INC.
;
; MOV AX,SP ;SS:SP = end of program
; SHR AX,4
; MOV BX,SS
; ADD BX,AX
; INC BX ;BX = first para. beyond program
; MOV AX,ES ;ES:0000 = first para. of program
; SUB BX,AX ;BX = program size in para.
; MOV AH,4AH ;Function to resize memory block
; INT 21H ;Carry will be set if failure
; JNC STILLGOING
; MOV AX,4C01H ;Failed to resize so terminate
; INT 21H
;STILLGOING:
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; One more step and we will be ready to hit protected mode!!! We must
;initialize the library by calling INITXLIB. This procedure will return an
;error code in EAX. A code of zero always means success under XLIBE.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CALL INITXLIB
OR EAX,EAX
JZ GOTPOWER
MOV AX,4C01H ;DOS termination function
INT 21H ;You will have to read after all.
;If you simply can't stand user
;manuals, then try throwing out
;some device drivers and TSRs.
GOTPOWER:
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; We don't want to mess around in real mode anymore. As you will shortly
;see, we can do about anything in protected mode that we could do in real
;mode, plus a whole lot more. Moreover, XLIBE makes protected mode easier
;than real mode. We will spend the rest of our time working from a 32-bit
;protected-mode subroutine called PMMAIN. We will get there with an XLIBE
;procedure called CALLPM. Just push the offset of PMMAIN on the stack and
;call CALLPM.
; There is one big assumption involved here: It is assumed that PMMAIN and
;all other 32-bit routines are contained in a segment called TSEG. Don't
;worry, TSEG can be larger than 64K if you live by the rules. Read the
;manual if you want to know what they are.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PUSHD OFFSET PMMAIN ;Must use a 32-bit offset
CALL CALLPM
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; XLIBE is going to use the return address from the above call to find its
;way back to real mode. You can get back to real mode by using the RET
;instruction provided that you have maintained the stack pointer. If this is
;not the case, then you can still get back with no problem. More about this
;later. When we get back, we are just going to terminate.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
MOV AX,4C00H
INT 21H
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Now we will declare our 32-bit segment. We will later talk about
;protected mode segments in general and about 32-bit segments in particular.
;Just hang loose for now. It is all simple.
; When we arrive at this segment from CALLPM, our segment registers will
;have been loaded by XLIBE. They will be set as follows: CS will have
;TSEG base and a 4Gb limit (Gb = gigabyte). SS will also have TSEG base and
;a 4Gb limit; however, code segments and data segments are distinguished in
;protected mode. We will have 4096 free bytes on the stack. DS will have a
;zero base and 4Gb limit. This is what is called a "flat" segment. ES will
;have TSEG base and a 4Gb limit (same as SS). FS will have DSEG base and a
;64K limit. DSEG is the data segment used by XLIB. Finally, GS will have
;DGROUP base and a 64K limit. DGROUP is the segment group created by the
;.DATA directive. If you are a high-level language programmer, then DGROUP
;is also where your compiler probably puts all of the near data.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TSEG SEGMENT PARA PUBLIC USE32 'CODE'
ASSUME CS:TSEG, SS:TSEG, ES:TSEG, FS:DSEG, GS:DGROUP
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Now let's look at the PMMAIN procedure below. You will see that it is a
;near procedure. This must be the case for all procedures called by CALLPM.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PMMAIN PROC NEAR
;!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
; We are in 32-bit protected mode
;!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; By the way, you will get all registers except segment registers and ESP
;at the values you had in them in real mode, including status flags (carry
;flag, zero flag, etc) and the interrupt flag. The stack got switched on
;you, so don't try passing stack arguments through CALLPM. If you have
;arguments, then send them across in registers (e.g. load a register with a
;pointer to a structure containing all arguments).
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Of course, no language tool can be legitimate unless it can say "hello"
;to the world, so let's take care of this important business now. We will
;use DOS function 02H for this purpose.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
MOV EBX,OFFSET HELLOWWORLD
MOV AH,02H
GETCHAR: MOV DL,CS:[EBX] ;Read with CS but don't write!!!
OR DL,DL
JZ GOODBYEWORLD
INT 21H ;DOS interrupt
INC EBX
JMP GETCHAR
HELLOWWORLD DB "Hello world!",0
GOODBYEWORLD:
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Did you forget that DOS is a real-mode system??? If not then you could
;be wondering how we got away with what we just did (i.e. INT 21H). The
;answer is simple. At this point, XLIBE is trapping all interrupts occurring
;in protected mode. It is then switching to real mode and relaying the call
;to the corresponding real-mode interrupt handler. Finally, it is switching
;back to protected mode and returning control to us. This is commonly called
;"reflection." We call it "deflection" in XLIB.DOC. Any interrupt will
;continue to be deflected until you install your own protected-mode interrupt
;handler for the interrupt.
; Therefore, we can still use our favorite software interrupts with one
;provision: These interrupts cannot return values in the segment registers.
;Such values would be overwritten with segment selectors on the way back to
;protected mode. More about segment selectors later.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Now, let's get down to real business. Your principal interest in
;protected mode was likely access to extended memory. Well, it is now there
;for the taking. However, we must play by the rules. If you just start
;punching around in extended memory, then you could get a nasty thing called
;a "page fault." We will talk more about this later. Also, somebody else
;might be up there - like your disk cache or your ram drive. Mess with those
;and you are going to feel real bad.
; The safe approach is to allocate the extended memory with the PMGETMEM
;function. Just load EAX with the number of bytes you want and call
;PMGETMEM. Let's get 64K.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
MOV EAX,10000H
CALL PMGETMEM
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; PMGETMEM will return with an error code in EAX. If EAX = 0, then the
;address of the allocated block will be in EDX. The actual size of the block
;will be in ECX, and a handle for the block will be in EBX. The allocated
;size will always be at least as large as your request. You will need the
;handle in EBX in the event that you later want to release the block;
;however, there is little need to worry about this. XLIBE will release it
;for you automatically when you terminate.
; Now, let's see if we got an error from PMGETMEM. If so, then we will
;return to real mode using the near RET instruction; otherwise, we will zero
;the entire allocated block just for fun.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
OR EAX,EAX
JZ ZEROMEMORY
RET ;Go back to real mode
ZEROMEMORY: SUB ECX,4 ;ECX is always a multiple of 4
MOV [EDX+ECX],EAX ;EAX = 0 from PMGETMEM
JNZ ZEROMEMORY
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; The RET instruction is an easy way to get back home, but suppose you had
;pushed some stuff on the stack since the call to CALLPM. Then RET would be
;potentially disastrous. In this case you get back to real mode by jumping
;to a procedure call RETPM. The following instruction would do the trick:
;
; JMP RETPM
;
;You can use this instruction just about anywhere.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Now, suppose you have a bug somewhere along here and you therefore wish
;to look at your register values. This is easy under XLIBE. Just use the
;INT 3 instruction.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
INT 3
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; INT 3 generates a breakpoint exception. XLIBE will trap this exception
;and print a report to the screen. This report will contain register state
;and other useful information. From the report screen you will be given the
;option to resume execution. XLIBE will attempt to trap and report all CPU
;exceptions in this manner. Expect to get plenty of them in protected mode.
;Don't worry, they are not going to crash your machine all the time like they
;did in the old days. XLIBE is pretty good at cleaning up your mess.
; See the special note below if you want to know how XLIBE is going to
;handle your FPU exceptions.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; OK. You already know enough about XLIBE to write some powerful code.
;You might not be interested in the remaining examples, so let's talk for a
;while about what you need to know concerning protected mode in general, and
;then you can get to programming if you wish.
; The principle difference between protected mode and real mode from the
;programmer's perspective is the interpretation of the segment registers. In
;real mode the value in the segment register is multiplied by 16 and then
;added to an offset to get an address. For example, consider: MOV AX,[BX].
;This instruction implicitly uses the DS register for the memory access.
;Suppose DS = 02FFH and BX = 4004H, then AX would be loaded from 6FF4H (or
;10H * 02FFH + 4004H). It's simple, but it is also very limiting.
; By the way, 4004H would be called the "effective" address while 6FF4H
;would be called the "linear" address. The "base" address of the segment is
;simply the linear address at offset zero. In this case, the base address is
;2FF0H.
; Now we will find out what stinks about real mode: The largest value
;you could have in DS is FFFFH (64K - 1). The largest offset you could have
;is also FFFFH. This means that the largest linear address you could get in
;real mode is 10FFEFH. That's 1 meg plus about 64K. Isn't much these days.
;You wouldn't be reading this if it were.
; In fact, you can't even get 10FFEF if you have only 20 address lines (as
;in the 8086). In this case you would be limited to FFFFFH, the largest
;number that can be expressed with 20 bits. That's where the one meg
;limitation came in.
; The addresses beyond FFFFFH and up to 10FFEFH are commonly called the
;"HMA" (high memory area). You get them from real mode when you have got
;more than 20 address lines (as in the 286 or higher). The "A20" you may
;have heard about is the 21st address line (the first one is numbered zero).
; In protected mode, the segment registers contain "selectors." Selectors
;index system tables called "descriptor tables." Under XLIBE, your selectors
;will be indexing the "local descriptor table" or LDT. The entries in these
;tables contain "descriptors." These are each eight bytes long. XLIBE sets
;them all up for you.
; The descriptors specify many things concerning a segment; however, two
;are of special importance. First, these descriptors specify the base
;address of the segment. Second, they specify the limit of the segment. The
;limit is the largest offset that can be used in conjunction with the
;segment. The nice thing about protected mode is that both the base and the
;limit can be as large as FFFFFFFFH (that's 4Gb - 1).
; One of the reasons that we use the term "protected mode" is the
;enforcement of the limits on the segments. Suppose you had DS loaded with
;a descriptor having FFFH limit, and suppose you tried to execute something
;like MOV AX,[1000H], then you will have violated protection rules and the
;processor will shut you down with an exception #13. Hence, memory outside
;of the segment is somewhat protected. Actually, there are other protection
;mechanisms far more important than this. More later.
; Observe that we could get mighty close to emulating real mode from within
;protected mode. We could load segment registers with base addresses less
;than FFFFFH and fix their limits at FFFFH. Then all we would need to do
;is make the processor interpret loads to the segment registers as changes
;to their base addresses (actually, a little more would be necessary). In
;fact this can be done. It's called "virtual 8086 mode." You are using it
;right now if you have something like EMM386, 386MAX, or QEMM386 loaded. You
;may be surprised to know that you have been using protected mode all along!
; So, the moral to the above story is: A segment register must never be
;loaded with anything but a selector to a valid descriptor. In real mode you
;could always execute MOV DS,AX. This isn't going to work in protected mode
;unless AX contains a selector. If it doesn't, then an exception #13 is
;headed your way.
; OK. The next major difference between the two modes has already been
;mentioned: In real mode, your offsets cannot be greater than FFFFH. In
;protected mode they can be as great as your segment limit, and that usually
;means 4 gig. By the way, there is nothing inherent to real mode that would
;logically prevent segment limits greater than FFFFH. The processor imposes
;this limit to enforce emulation of the 8086. If we could persuade the
;processor to lift this restriction, then we would find ourselves with a
;really powerful real mode. In fact this can be done on the data segments,
;and is done in some software (e.g. HIMEM.SYS).
; Perhaps you have heard of something called the "flat model" or
;"unsegmented model." This is a protected-mode model in which we set all
;segment base addresses to zero and set all segment limits to FFFFFFFFH.
;This makes life real easy, and it's probably where we are headed in the
;future. XLIBE tries to get you as close to this model as it can so that you
;won't have to be changing your code when your future finally gets here.
; Now let's talk about 32-bit processing as opposed to 16-bit processing.
;There are a few things you need to know. Notice that we have "USE32" on the
;TSEG segment declaration above. This is why we call TSEG a 32-bit segment.
;Segments you have used in times past had the USE16 attribute (the default).
;DSEG and DGROUP are also USE16 segments. You have probably guessed that
;USE16 gives you a 16-bit segment. The difference derives from a peculiarity
;of the processor. For most instructions, the processor has both a 16-bit
;version and a 32-bit version. The peculiarity is that the op codes are
;generally the same. Consider PUSH AX as opposed to PUSH EAX. Would you
;believe that they are encoded exactly the same? The op code is 50H either
;way.
; So how do we tell the difference? Well, it's done with a single bit in
;the code segment descriptor. If this bit is set, then the instruction will
;be interpreted as having a 32-bit operand. It will be interpreted as a
;16-bit instruction otherwise. This bit is called the "D bit" (default
;operand/address size).
; So, what if you really wanted a PUSH AX even when this curious bit is
;set? You do this by encoding an "operand prefix" in front of the
;instruction. The prefix is 66H. So if we want PUSH AX from within 32-bit
;mode, then we encode the instruction as 66H followed by 50H. Conversely, if
;we wanted PUSH EAX in 16-bit mode, then we must also encode it as 66H
;followed by 50H. Thus, the 66H temporarily places the processor in the
;opposite mode dictated by the D bit.
; The USE32 directive informs the assembler that we intend to execute in
;the declared segment with the D bit set. This information lets the
;assembler know that it must stick operand prefixes in front of 16-bit
;instructions. Accordingly, USE16 tells the assembler that we are going
;to execute in the declared segment with the D bit clear. Now the assembler
;must stick the operand prefix in front of 32-bit instructions.
; A similar situation exists for base registers and index registers. For
;example, MOV AL,[EBX] and MOV AL,[BX] are identically encoded apart from a
;prefix. The prefix in this case is 67H. A 67H enables a MOV AL,[BX] in
;a 32-bit segment, or MOV AL,[EBX] in a 16-bit segment. The USE32 and USE16
;directives tell the assembler where to insert 67H.
; What if we had MOV AX,[BX] in a 32-bit segment? Then we must encode both
;prefixes (67H must be first).
; You have probably gathered that 16-bit instructions are bad in a 32-bit
;segment. They obviously require more memory. What isn't obvious is that
;they burn up CPU time (typically 1 clock each on the 486). So avoid 16-bit
;registers while in TSEG. 8 bit registers are OK in either kind of segment.
; Observe that the D bit has little to do with protected-mode. We could
;run a protected-mode program in a 16-bit segment, but then we have to pay
;a price for using 32-bit registers. That just isn't smart. The only
;association between the D bit and protected mode is that you must be in
;protected mode if the D bit is set. There is no such thing as 32-bit
;real mode, even though it is conceptually possible.
; OK. There is one other thing that you should perhaps understand. Its
;called "page mode," but the concept is a little complicated, so we have
;placed it at the bottom of this file. You can read it if you like, but
;will be OK without it.
; If you are ready to leave, then we can terminate our program with the
;following lines:
;
;
; RET ;Go back to real mode
;PMMAIN ENDP
;
;TSEG ENDS
; END
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Back to our discussion about XLIBE. From now on we are going to deal
;with you bad guys.
; Let's suppose you have an IO device which maps to extended memory
;addresses. You need to read or write to these addresses. The memory is
;supplied by the device and is not recognized as ordinary RAM by the
;operating system. The operating system may not even know that it is there.
;Let's suppose that the device map begins at the 16th meg boundary (1000000H)
;and is 64K long.
; It would not be wise just to start poking and peeking around 1000000H.
;There is a problem in that your device maps to "physical" addresses whereas
;your instruction code is using "logical" addresses. They may not be the
;same. See the discussion about page mode below if you want to understand
;the difference.
; You need to create a logical address space for accessing the device.
;This is very simple. Just call PMMAPIO with EDX = the physical address of
;the device and EAX = the size of the window.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
MOV EDX,1000000H
MOV EAX,10000H
CALL PMMAPIO
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; PMMAPIO returns an error code in EAX. If EAX = 0, then EDX will equal
;the starting address at which the device should be accessed. We will check
;out this error code before we continue.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
OR EAX,EAX
JZ MOREHARDCORE
RET ;Back to real mode
MOREHARDCORE:
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; OK. Now let's suppose you have a great big database on disk that you
;have never been able to completely read into memory because of DOS
;limitations. We are fixing to load the whole thing. First, we must
;allocate memory to contain the file. Let's do that now. We are going to
;assume that the file will never be larger than one meg, but you could
;increase the assumed limit if you wanted.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
MOV EAX,100000H ;Get 1 Meg of memory for file
CALL PMGETMEM
OR EAX,EAX ;See if an error occurred
JZ WAYDOWN
RET ;Back to real mode
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Next, we need to set up a file control block (not a DOS FCB) to describe
;the file to XLIBE. XLIBE will expect the control block to be in the form of
;the structure below.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
XFILE STRUCT
CONDCODE DWORD 0 ;Condition code from file operation
FNAME BYTE 68 DUP(0) ;ASCII file path (zero terminated)
FHANDLE WORD 0 ;File handle assigned by DOS
FPTRMODE WORD 0 ;File pointer reference
FPTR DWORD 0 ;Initial file pointer
BLOCKADR DWORD 0 ;Memory source/destination address
BLOCKSIZE DWORD 0 ;Size of transfer block in bytes
BUFFERADR DWORD 0 ;Address of memory buffer in 1st meg
BUFFERSIZE WORD 0 ;Buffer size in bytes
CONTROL WORD 0 ;Control word
XFILE ENDS
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;TASM Only:
; If you are a TASM programmer, then don't use the structure above. Use:
;
;XFILE STRUC
; CONDCODE DD 0
; FNAME DB 68 DUP(0)
; FHANDLE DW 0
; FPTRMODE DW 0
; FPTR DD 0
; BLOCKADR DD 0
; BLOCKSIZE DD 0
; BUFFERADR DD 0
; BUFFERSIZE DW 0
; CONTROL DW 0
;XFILE ENDS
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;Let's suppose that the filename is JUNK.DAT and that this file is in the
;current directory. If you want to run this program, then create a small
;text file called JUNK.DAT in the current directory. We are going to get
;the assembler to put our file name in the structure. The rest we will punch
;in ourselves. Remember that EDX is the linear address of the memory block
;where we are going to load this file. ECX is the size of the block. We
;obtained these values from PMGETMEM above. Also, remember that ES is loaded
;with a selector to TSEG.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ALIGN 4 ;Unaligned data will slow you down
FCB XFILE <0,"JUNK.DAT"> ;File control block
WAYDOWN: MOV ES:FCB.BLOCKADR,EDX
MOV ES:FCB.BLOCKSIZE,ECX
MOV ES:FCB.BUFFERSIZE,0H
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; OK. Lets get the file and talk about it later. We will need to call
;PMXLOAD. PMXLOAD will expect EAX to contain the linear address of the file
;control block. Here we go.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
MOV EAX,TSEG ;Get segment of control block
SHL EAX,4 ;Multiply by 16 and add offset
ADD EAX,OFFSET FCB ;EAX = linear address now
PUSH EAX ;We will use this again
CALL PMXLOAD
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Now, we will explain what we just did. BLOCKADR is the address of the
;memory block where we want the file to be loaded. BLOCKSIZE is the size of
;this block. PMXLOAD will not load past the end of the block since that
;could be very dangerous to you or whoever else might be in memory. Now, DOS
;is going to access the disk for us, but DOS can't work with extended memory.
;So, we set up a buffer in conventional memory for DOS. PMXLOAD will handle
;the transfers from the buffer to extended memory. You could supply your
;own buffer address and size in BUFFERADR and BUFFERSIZE; however, if you
;will just set BUFFERSIZE to zero, then XLIBE will supply its own buffer.
; PMXLOAD will return an error code in both EAX and CONDCODE (same error
;code). We will check it now.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
OR EAX,EAX
JZ GOTFILE
JMP RETPM ;Back to real mode
GOTFILE:
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Notice that if an error occurs, then we transfer control back to real
;mode with JMP RETPM rather than RET. This is because we've got some stuff
;on the stack now; namely, the linear address of our file control block. Of
;course a POP EAX followed by a RET would still work.
; OK. Suppose you play around with memory image of the file, perhaps
;making a few modifications. Now you want to save it. The file control
;block should be defined as before, except BLOCKSIZE and BLOCKADR should
;specify the address and size of the memory block you are going to save.
;PMXLOAD modified BLOCKSIZE in the file control block. It was set to the
;actual size of the file that it loaded. This means that unless you have
;changed the size of the memory image, then you need to make no further
;modifications to the file control block to perform the save. Just call
;PMXSAVE with the address of the control block in EAX. Here we go.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
POP EAX ;Get FCB address
CALL PMXSAVE
OR EAX,EAX ;See if an error occurred
JZ FILEISSAVED
RET
FILEISSAVED:
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; XLIBE can also perform random reads and writes with files. See the
;manual if you want to know more.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; One more topic. This concerns interrupt handlers. These are real devils
;in any mode. Unfortunately, XLIBE can't simplify matters as much as it would
;like. This is because XLIBE must work in conjunction with other software
;(VCPI or DPMI) to give you all of this protected-mode stuff. This other
;software doesn't handle interrupts the same, and there isn't much that XLIBE
;can do to smooth out the lumps. You better read the manual on this one.
; Anyway, we are going to install a simple timer-tick interrupt which will
;print an asterisk to the screen with each timer tick. We are going to use
;routines in the file PMIO.INC to do the printing. You will see that we have
;INCLUDE PMIO.INC several lines down in the code.
; PMIO.INC is a very handy little file and is very simple to use. Examine
;the file if you want to know more. The comments in the file explain how to
;use the PMIO procedures.
; Let's clear the screen before we get started with our interrupt handler.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CALL CLS
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; OK. We are going to install our own protected-mode interrupt handler for
;the timer tick. The timer tick is a hardware interrupt on IRQ 0. First, we
;need to get the current protected-mode interrupt vector so we can restore it
;when we are done.
; Now the timer tick is generally at vector eight (INT 8), but we must deal
;with the possibility that XLIBE has remapped interrupts. We can't assume that
;IRQ 0 is still assigned to INT 8. The current mapping is contained in the
;XLIBE data area (DSEG) in a variable called IRQ0INTNO. Let's get it now.
;Remember that FS contains a selector for DSEG.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
MOV AL,FS:IRQ0INTNO
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; OK. To get the current vector, we need merely to call PMGETPMIV (get
;protected-mode interrupt vector) with the vector number in AL. The address
;of the current interrupt handler will be returned in CX:EDX. Here we go.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CALL PMGETPMIV ;No error code from this call
PUSH ECX ;Save handler address on stack
PUSH EDX
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Now we will set our new vector. We must call PMSETPMIV with AL = the
;interrupt number and CX:EDX = the new handler address. CX must be a segment
;selector. Our new handler is called TIMERINT. It is located just a few
;lines down. We will get there in just a moment. PMSETPMIV will return an
;error code in EAX. We will check this, as always.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PUSH CS ;Put handler address in CX:EDX
POP ECX
MOV EDX,OFFSET TIMERINT
CALL PMSETPMIV
OR EAX,EAX ;Check error code
JZ WATCHTICKS
JMP RETPM ;Back to real mode
WATCHTICKS:
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Notice that we treated PUSH CS as though it put 4 bytes on the stack.
;It did. In 32-bit mode, the processor tries to keep the stack aligned at
;MOD 4. So, it padded the PUSH with a two-byte zero. It will always do
;this with segment registers (on far calls, on interrupts, on everything),
;and you would do well to remember it.
; OK. Now we need a little loop to delay long enough for a few timer
;ticks to happen. There are about 18.2 of them in a second. If you have
;a 486-33, then the next loop will work fine. If you have a 386, then you
;may be watching ticks for a while.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
MOV ECX,0FFFFFFH
WAITAWHILE: LOOP WAITAWHILE ;Asterisks are being printed
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; That's enough. Let's put the old vector back.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
POP EDX
POP ECX
MOV AL,FS:IRQ0INTNO
CALL PMSETPMIV ;Will ignore any error here.
;We couldn't do anything else.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Here is where we go back to real mode for good. But keep on reading.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RET ;Goodbye protected, ole pal
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; Now, let's look at our protected-mode handler. Comments are below.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TIMERINT PROC FAR
STI
PUSH EAX
PUSH DS
MOV DS,CS:CSDSEGSEL ;Load DSEG selector
MOV DS,FLATDSEL ;Load flat selector for PMIO
MOV AL,"*"
CALL PCH ;Print AL as ASCII
CLI
MOV AL,20H ;Send EOI to 8259 master
OUT 20H,AL
POP DS
POP EAX
IRETD
TIMERINT ENDP
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; As you probably know, we are not supposed to assume anything about
;anything in an interrupt handler, including segment register settings. Now
;XLIBE has recorded our selector values in DSEG (see manual). However, we
;have a little problem here: We need the DSEG selector to get them. The
;way we circumvent this dilemma is by putting a copy of the DSEG selector in
;your code segment where you can always read it. XLIBE has already done
;this for you. It placed the selector in CSDSEGSEL.
; After we have loaded DS with DSEGSEL, we then load it with the flat
;selector. This is recorded in FLATDSEL.
; You might be wondering why we didn't use a DOS function to do our
;printing. It's because you can bring a system down real hard and real fast
;by calling DOS in an interrupt handler. The problem occurs when DOS is
;itself interrupted. DOS is not generally reentrant. The print routines in
;PMIO are very robust. They are also fast.
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
; OK. You are hopefully an XLIB programmer now. Remember that XLIB is not
;free. You must register it once you have developed any program with it.
;The fee is only $50 ($70 with technical support). If you think that is bad,
;then you should look at the retail DOS extenders. You are talking about
;a lot more money and a lot more work. We appreciate your business
;
; TechniLib
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PMMAIN ENDP
INCLUDE PMIO.INC ;Protected-mode IO routines
TSEG ENDS
END
;*****************************************************************************
; Special Notes
;*****************************************************************************
; ++++++++++++++++++++++++++++
; + Writing Libraries +
; ++++++++++++++++++++++++++++
;
;
; You can give high-level language programs tremendous power by linking
;them with protected-mode libraries developed with XLIBE. See the EASYX.ASM
;file for an example.
;
;
; ++++++++++++++++++++
; + Page Mode +
; ++++++++++++++++++++
;
;
; We discuss something here that's a little technical, but extremely
;enlightening. It's called "page mode," available only in protected mode or
;in virtual 8086 mode, which is of course a subset of protected mode. In
;page mode, memory addresses specified in instruction code undergo a little
;mathematical translation before they are actually applied to the physical
;memory. So what you ask for isn't always what you get. For example, if
;you write something to address 10000H, it might actually go to 20000H. This
;isn't bad as long as when you read from 10000H you also get 20000H, and
;indeed you will. Incidentally, the address you specify is called a
;"logical" address. The address you actually get is called the "physical"
;address.
; Now, a lot of mysteries may have just been explained to you. For
;example, you know that most of your programs must reside in the first meg.
;You also know that many of your programs consume most of the available
;memory in the first meg. How then do DESQview, Windows, OS/2, etc. run all
;of these programs at the same time??? Well, you give each program a
;different translation formula. Stick the first program in the first meg and
;give it one-to-one translation. No trickery here. Stick the second program
;in the second meg and then add 1 meg (100000H) to every address it tries to
;read and write. Remember, this program thinks it's in the first meg, so
;that's where it's going to be reading and writing. But, because of the
;translation, it's going to be getting the second meg. This program has been
;fooled. It has been hornswoggled by page mode.
; Perhaps you have wondered how your memory manager put your device drivers
;and TSRs in upper memory where ROM is supposed to be. The answer is page
;mode again. The device drivers and TSRs are actually in extended memory.
;The logical addresses which would otherwise belong to the ROM area have been
;translated to these extended memory addresses.
; Before explaining what all this has to do with you, let's explain the
;translation method. The logical address you specify is of course 32 bits
;wide. We are going to divide these three ways: the 10 upper bits, the
;next ten bits, and the lowest 12 bits. The translation runs thus: The 10
;highest bits are used as an index to a table which has 1024 entries. These
;entries are 4 bytes wide so the table consumes 4K. These entries are
;physical addresses to other tables which are also 4K in size. We use your
;upper 10 bits to pick the appropriate table. Your next 10 bits will be used
;as an index to the second-level table. The entries in this table supply the
;upper 20 bits to the physical address you are actually going to access. The
;lowest 12 bits of the physical address are supplied by the lowest 12 bits in
;your logical address. A mess isn't it. Don't worry, you are not responsible
;for handling this mess, but sometimes XLIBE is.
; Now, the second-level table supplies all but the 12 lowest bits of the
;physical memory address; therefore, the addresses in this table are spaced
;in memory at least 4096 bytes apart (2 ^ 12 = 4096). The memory is
;effectively divided into 4K units along 4K boundaries. These 4K units are
;called "pages," hence the term "page mode."
; The first-level table is called a "page directory." The tables at the
;second level are called "page tables." You typically give each program its
;own page directory and page tables. This is how we use a different
;translation method for each program.
; One of the most effective ways to protect a physical page from a
;particular program is to simply avoid placing the address of the page in the
;program's page tables. If the address of a physical page is not anywhere
;in the page tables, then there is no way that the program can access it,
;provided of course that we also prevent the program from playing with the
;page tables themselves. Hence, we could completely shield one program from
;another. This largely explains how OS/2 and Windows NT achieve such high
;degrees of protection.
; Now the page tables are themselves pages. That is, they are 4K in size
;and are situated on 4K physical address boundaries. This means that their
;addresses are zero in the lowest 12 bits. The pages they catalog are also
;zero in the lowest 12 address bits. This means that for each entry in the
;page directory and for each entry in the page tables we have 12 bits to play
;with (the lowest 12) because we never need them for address specification.
; An operating system can use certain of these bits to implement other
;protection mechanisms of the processor. For example, the operating system
;can use one of these bits to designate the page as read-only. Try to write
;to it and you are going to get a page fault (exception #14). A page can
;also be marked as privileged. This means that the operating system can
;access it but most other programs cannot.
; Another important bit in the page tables is the "present" bit. This bit
;is set if there is actually a physical page available for the implied
;logical address. What happens when you try to access a logical address
;whose page table entry is marked not present? Well, you are going to get
;another page fault. Under XLIBE this almost certainly means that your
;program is going to get terminated. Indeed, XLIBE will usually be
;responsible for terminating you (gently if at all possible). Which explains
;one of the reasons why you need to understand page mode. Page faults are
;going to become a major part of your protected-mode life. If your program
;has a wild read or write, or a bad JMP or CALL, or a RET or IRET with
;a mismanaged stack, then page faults are likely.
; Some operating systems and memory managers have "virtual memory." This
;is where you are using disk to emulate memory. The operating system may
;give you a logical address block which really doesn't have any physical
;memory to back it up. The page table entries for this logical address block
;are all marked not present. When you try to access one of these logical
;addresses, the resultant page fault is trapped by the operating system,
;which then pulls the requested page off the disk and places it in a special
;memory area designed for such purposes. Your page table entry is then
;pointed to this location and is marked present. Finally, control is
;returned to you. You may never know what happened.
; You can actually use virtual memory under XLIB. Just get a DPMI host
;with virtual memory capabilities.
+++++++++++++++++++++++
+ FPU Exceptions +
+++++++++++++++++++++++
; Floating point exceptions are handled a bit differently than CPU
;exceptions by XLIBE. Suppose you had a major goofup in your code like this:
;
; FLD1 ;Load 1.0
; FLDZ ;Load 0.0
; FDIV ;Compute 1.0/0.0 (very sinful)
; FSTP ST ;Pop the "quotient"
;
;The FDIV will cause a zero divide exception in the FPU. This exception will
;not be signalled to the CPU until the next floating point instruction. So
;the FSTP ST instruction is where things are going to happen.
; Under default behavior, XLIBE is going to trap this exception and display
;a report describing the cause and location of the exception. XLIBE will
;terminate your program after presenting the report. If you don't like the
;default behavior of XLIBE, then XLIBE can be configured such that it will
;turn control over to you when such exceptions occur. Study the OFLAGS
;variable in the XLIB documentation for more about this.